A software defined network (SDN) is a new network architecture, and compared with internet protocol (IP) route search used in a conventional network, the SDN can implement flexible control over network traffic, so as to provide a desirable platform for innovation of core networks and applications and is a direction of network architecture development in the future.
As shown in FIG. 1, the SDN generally includes two parts: a controller 110 and switches 120. The controller 110 is separately connected to each switch 120 on the network. The switches 120 on the network are topologically connected to each other. The switch 120 on the network may be connected to user equipment 130 and a server 140. When the user equipment 130 needs to perform data communication with the server 140, the controller 110 calculates and obtains a suitable forwarding path between the user equipment 130 and the server 140, and sends a flow entry to a switch 120 on the forwarding path, so that the switch 120 receiving the flow entry can forward data according to the flow entry, and the data communication is completed between the user equipment 130 and the server 140.
If the network is under an illegal attack, the switch 120 receives a large quantity of attack packets, and the controller 110 cannot obtain a suitable forwarding path through calculation. Therefore, the attack packets cannot match with any flow entry in the switch 120. According to an agreement in a current protocol, when receiving a packet having no matching flow entry, the switch 120 needs to send a Packet in message to the controller 110, so that the controller 110 looks for a forwarding path for the packet having no matching flow entry. For example, during an illegal destination IP address, destination addresses of these attack packets do not exist on the network controlled by the controller 110, and therefore the controller 110 cannot find a forwarding path for these packets. Therefore, the controller 110 sends a Packet out message to the switch 120 that sends the Packet in message, where the Packet out message includes an Address Resolution Protocol (ARP) data packet. After receiving the ARP data packet, the switch 120 sends, using ports (except a port through which the attack packets enter), the ARP data packet to switches 120 that are connected to these ports. After receiving the ARP data packet, the switches 120 connected to these ports perform matching between the ARP data packet and flow entries in the switches 120. Destination addresses of the attack packets are fictitious, and therefore the ARP data packet cannot match with any flow entry either. As a result, according to the agreement in the current protocol, these switches 120 send Packet in messages to the controller 110, so that the controller 110 looks for a forwarding path for the packet having no matching flow entry, and then the controller 110 returns Packet out messages. In such a repeated cycle, a topological connection relationship between the switches 120 is relatively complex, and therefore a switch 120 may separately receive, using multiple ports, ARP data packets forwarded by other switches 120, which results in multiple times of flow entry query, greatly wasting resources of the switches 120. In addition, when receiving an ARP data packet using one port, each switch 120 sends a Packet in message to the controller 110 once. Therefore, if receiving an ARP data packet using multiple ports, each switch 120 sends a Packet in message to the controller 110 for multiple times. When multiple switches 120 on the network receive ARP data packets using multiple ports, an amplification effect is caused, where a large quantity of Packet in messages are sent, and this even leads to a broadcast storm finally, which greatly wastes calculation resources of the controller 110 and bandwidth resources of the switches 120.